Skip to content

ci(root): block release when rel/latest is ahead of master#9153

Merged
rashadjnizar merged 1 commit into
masterfrom
HSM-436-block-release-when-rel-ahead
Jul 2, 2026
Merged

ci(root): block release when rel/latest is ahead of master#9153
rashadjnizar merged 1 commit into
masterfrom
HSM-436-block-release-when-rel-ahead

Conversation

@rashadjnizar

Copy link
Copy Markdown
Contributor

HSM-436

Summary

Back merges from rel/latest into master (e.g. #9127) are missed frequently. When that PR is skipped, rel/latest stays ahead of master, and the next release merges/publishes on top of an out of sync rel/latest.

This PR adds a verify-back-merge gate to npmjs-release.yml that fails the release if rel/latest is not an ancestor of master, forcing the previous back merge to land before a new release can run.

What changed

  • New verify-back-merge job runs git merge-base --is-ancestor origin/rel/latest origin/master. Exit 0 → release proceeds; otherwise it errors, prints the offending commits, and fails.
  • release-bitgojs now needs the gate and adds && needs.verify-back-merge.result != 'failure' to its if.

Behavior

Scenario Gate Release
Normal release, back-merge landed success runs
Normal release, back-merge missing failure blocked
Recovery mode (rel/latest intentionally ahead) skipped runs

@rashadjnizar rashadjnizar requested review from a team as code owners June 30, 2026 23:13
@linear-code

linear-code Bot commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

HSM-436

@zahin-mohammad

Copy link
Copy Markdown
Contributor

@claude

@github-actions

github-actions Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Claude finished @zahin-mohammad's task —— View job


Code Review Complete ✅

Overall Approach

The implementation correctly addresses the problem of preventing releases when back-merge PRs are missed. The use of git merge-base --is-ancestor is the appropriate git command for this check.

Job Implementation (verify-back-merge)

  • Conditional logic: Properly skipped in recovery mode with if: ${{ !inputs.recovery-mode }}
  • Checkout strategy: Correctly checks out master with fetch-depth: 0 to get full history
  • Git operations: Fetches rel/latest explicitly before the ancestor check
  • Error handling: Provides clear error messages and logs divergent commits
  • Timeout: Reasonable 10-minute timeout for a lightweight git operation

Job Dependencies

The release-bitgojs job correctly:

  • Adds verify-back-merge to its needs array
  • Updates the conditional to check needs.verify-back-merge.result != 'failure'
  • Uses always() to ensure the condition is evaluated even if dependencies are skipped

Recovery Mode Handling

The logic properly handles the three scenarios mentioned in the PR:

  • Normal release with back-merge: gate succeeds, release runs
  • Normal release without back-merge: gate fails, release blocked
  • Recovery mode: gate skipped, release runs

🔍 Minor Observations

  1. Git fetch strategy: The explicit fetch of rel/latest is correct since checkout only fetches master
  2. Error messaging: Clear and actionable error messages that explain what to do
  3. Exit codes: Proper use of exit 0/1 for success/failure

📋 Testing Considerations

The implementation should be tested with:

  • Normal scenario where rel/latest is not ahead
  • Scenario where rel/latest is ahead of master
  • Recovery mode scenarios

Summary

This is a well-implemented solution that effectively prevents the described problem. The git logic is sound, error handling is comprehensive, and the integration with the existing workflow is clean. The PR successfully addresses HSM-436 with a robust gating mechanism.


Job Run: View Logs | Branch: HSM-436-block-release-when-rel-ahead

@rashadjnizar rashadjnizar merged commit 08654af into master Jul 2, 2026
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants